That calls for a celebration! :)

By "conclusion" he meant that this comment has a lot of upvotes. There's nothing official about it and there are other comments with even more 👍 .

@Mouvedia Something that's somewhat official about it is that the plan to switch to ?? was presented to TC39 in January 2018 with some discussion but overall a relatively supportive committee.

Note that there is a parallel change for nullish coalescing at tc39/proposal-nullish-coalescing#23 (to use ??: syntax).

Too many ?... and ??. looks too close to ??: which very harmful to readability...

const city = staff??.company??.address??.city??:defaultCity;

PS. Compare to my syntax suggestion:

const city = staff!.company!.address!.country??defaultCity;

@hax Nullish coalescing is a binary operator, so it normally would be written with spaces:

const city = staff??.company??.address??.city ??: defaultCity;

I think the spacing makes it reasonable to distinguish the operators from each other. As you mentioned in your original comment (#34 (comment)), !. conflicts with TypeScript, which seems really concerning to me, even if there are migration paths. My impression is that #34 is still the best place to discuss syntax alternatives, and this PR discussion is best focused on the PR itself and whether it follows from previous discussions.

My reading of #34 is that the four operators in this PR have by far the most support. See #34 (comment) and the comments immediately above and below it for a poll of various alternatives. (And, as mentioned, TC39 seems to be mostly in favor of this syntax, and they're the ones actually making the decision.) Hopefully most people are at least agreed that this is an improvement over the original ?., ?.[, ?.(, which is what this PR is replacing.

Even with spaces, I still prefer @hax's syntax suggestion, and agree that the similarity between the two operators is rather confusing and doesn't help quick reading / understanding of code. This just looks much more readable to me:

const city = staff!.company!.address!.country ?? defaultCity;

And so does this:

const city = staff?.company?.address?.country ?? defaultCity;

@hax, @lehni Discussion about the syntax must go in #34, not here. (But please do not repeat arguments you’ve already done.)

@claudepache What do you think of this PR?

@littledan

What do you think of this PR?

I haven’t had time to review it yet. But yes, I'm favourable to switch to that syntax, on condition that the syntax of nullish-coalescing is also changed (tc39/proposal-nullish-coalescing#23 or anything else).

@alangpierce Coding style can help, but these too close symbols also restrict the options of coding style. For example, you can not also add spaces around ??. for any reason:

staff??.company_name??.very_long_address??.#private_field // not very clear

staff ??. company_name ??. very_long_address ??. #private_field // better

staff ??. company_name ??. very_long_address ??. #private_field ??: default_value // unfortunate...

Try two spaces...

staff ??. company_name ??. very_long_address ??. #private_field  ??:  default_value 

Maybe we need three?

staff ??. company_name ??. very_long_address ??. #private_field   ??:   default_value

...So, see the problem?

Note, I just use !. for comparison because I believe it's the best option, but ?& also better than current combination in readability. Eg.

staff ?&. company_name ?&. very_long_address ?&. #private_field ?? default_value

And ?> (though it may have other problems)

staff ?>. company_name ?>. very_long_address ?>. #private_field ?? default_value

My reading of #34 is that the four operators in this PR have by far the most support.

Unfortunately the supporters all ignore the readability problem of ??. with ??:.

My impression is that #34 is still the best place to discuss syntax alternatives

The thread is already too long to catch. So maybe we should create a new issue.

What conclusion #51 ?

Are we seriously considering ??. and ??: as better than ?. and ?? for his proposal? I don't know where anyone is seeing a consensus that ??. is more desired or accepted than ?. by the community at large. In fact, it seems that ?. is far more accepted based on #51. I find ??. to be very heavy and unsightly, and in all honesty don't really want to be writing code littered with this verbose operator...

@jrista Please use #34 for feedback related to syntax.

I've commented in the other thread, but I have to say, this PR and the direction this proposal is now taking is very, very concerning. Ergonomics, understandability, verbosity. We are starting to head in the wrong direction on all fronts, and I truly hope this PR does not get merged.

@littledan If you still think that this PR should be merged, could you apply the requested changes?

I don't know that the debate over the operator has been settled. At this time, it still appears as though, despite it's supposed inconsistency, ?./?? is still by far the more preferred operator. Discussions on the operators seem to have stalled, but I don't believe that means the debate has ended, nor that ??. is what we should be using.

I presented both options to the committee last week and strongly advocated for the current syntax, calling out the strong community support. Both proposals had hard vetoes that prevented stage advancement:

• ?. because of inconsistency and overloading the meaning of . for bracket/method access.
• ??. because of the impact to the token for the null coalescing operator.

Paring back the proposal to only support ?. and opt-out of bracket and method access also received strong opposition. The absence of symmetry between member and bracket access and the choice of token ruling out future extensions to optional method/bracket access were cited as reasons that would block advancement of only ?..

There was no strong opposition to ??. ??( ??[ assuming null coalescing could find a better token (eg: not ??:). ??? and ||| were floated as possible alternatives.

Looking at the poll results for possible token options, there are really only two options and we've definitively ruled out one. I suspect that hard constraints settle the syntax debate, but I'm open to alternatives.

Is there a good place for discussion? Eg; I am curious what made ??: unacceptable. I assume this PR chain would not be the best place for follow-up questions and alternate suggestions, however.

@rattrayalex Some people didn't like the colon. Not sure what more there is to say; I guess it makes it less analogous to ||.

Cool, thanks @littledan. Perhaps they could be persuaded (much of es syntax design seems very constraint-driven). I assume you're working with the fine folks over at optional chaining. May be worth opening an informal bikeshed poll over on the other repo.

IMO null coalescing should be ||| as it's the only one that makes intuitive sense and leaves open the possibility to an &&& operator where 0 and the empty string are considered truthy.

That would also open up ?? to optional chaining without having that pesky . for square bracket notation.

@selipso in the TC39 meeting this week it was brought up that if === is a stricter ==, then ||| would be a stricter ||, and since || deals with truthiness, ||| would need to deal with true - a compelling argument that seemed to convince many people that ||| is not an option for this proposal.

Then by that logic ||| is 'stricter' than || because nullish types are more limiting than the loosey-goosey || where !(0 || '') === true. Perfectly intuitive to me and easily explainable to even my high school students that I teach programming to.

Since we have only one point of reference for this syntax (== vs ===) I don't think 'stricter' is the right word for it but rather a "restriction of scope" in the underlying values comparison. We are essentially restricting scope by adding a third character in both cases.

With == vs === we are restricting scope to exact matches of the underlying data type. With || vs ||| we are restricting scope from "falsy" values to only null and undefined values.

@selipso I think we should learn from failure of visually too close operators. The mainstream coding style now only allow === and forbidden == to avoid the confusion and accidently typos, there is also a rule which forbidden | and & to avoid potential confusion/typo with || and &&, so it's hard to convince the community adding ||| (and adding &&& for consistency) would be a good idea.

Note we can forbidden == because all == use cases could be converted to === with explicit type cast. We can forbidden & and | because most modules do not need bitwise operations, and we can choose to opt in if we really need bitwise ops in special modules. But we can't forbidden || because it's very correct to use || as logical operator, both || and ||| have very common use cases. This is why we need null coalescing operator, and I think as the motivation of some linter rules suggest, we'd better use syntax which have enough distance to avoid the confusion and typo.

@hax I, for one, would be fine with || being “less recommended” compared to |||. The concept of ‘falsy’ is a sticking point in JavaScript for both new and experienced programmers alike (esp. coming from C). I still see codebases with both == and === used cleverly and also appropriately. It will never be forbidden to use older syntax, but when some operator does something very similar to another operator, there is no need to add a mental switching cost with a different control character.

This would also free up optional chaining (which IMO is a more exciting and practical language feature) to use either ?. or ??., or even both! Makes everyone happy.

@hax There are definitely valid current uses of ==, and not all == should nor could be converted to === and still maintain the desired functionality. I commonly use variable == null to do null or undefined checks rather than falsy checks, for example.

@jrista No. All valid use cases of == can be replaced by === and get the better clearance and readability.

But variable == null is ok, even it could be replaced by variable === undefined || variable === null. It's very common we don't care about the difference between null/undefined, yes I myself also use x == null. But in all other cases, we should use === in engineering. (Note, it always ok to ignore all coding style if you are writing toy project or one-time script. But I'm assuming we are discussing professional programming which your codebase would be long-live and involve team collaboration.)

@hax It may be that you can, one way or another, find a way to eliminate ALL == and replace them with ===. Is that always the best way? It can needlessly increase the verbosity of code...and depending on the project and the nature of the data it may be very common to need to do null/undefined checks, and pounding out the full variable === null || variable === undefined quickly becomes tedious and mind numbing.

I find value in == in some cases, though, beyond just the variable == null case. Another valid example, IMO, is when you are working with "dirty data", which sometimes occurs with existing APIs. I've had to write code over the years that needs to work with APIs that are not properly versioned in a detectable way, for which multiple versions may be deployed and used and poor version management coupled with unexpected API deployments can wreak havoc, and where certain data such as numbers may be quoted or not, and where magic numbers are often used (ugh, old APIs...). For example 0 == '0' can be quite useful, since the data may be '0' or 0 depending on the API version.

I guess I try to be pragmatic rather than dogmatic when it comes to which operator to use. When I use ==, I ALWAYS comment in the code as to why, though, as there have been times when I've worked with more dogmatic developers who will happily convert every == they see it to === without considering the implications. ;) As often ends up being the case, I am able to introduce a little bit of pragmatism into those dogmatic individuals and simplify their lives a little bit once they learn how useful == can be in these special cases. ;D (And yes, I would consider them special cases...special, and completely valid.)

I ALWAYS comment in the code as to why

If you add comments for every == usage, it's definitely ok to use == 😂 But why not just write a === Number(b) to make your intention explicitly? IMO, comments are always last resort. If we can make the code self-describing, we'd better write code instead of comments.

though, as there have been times when I've worked with more dogmatic developers

You may think me (and many) as "dogmatic", we can argue it in other place (we already offtopic in this issue) but that's the real problem in collaboration. In a big team, you have to consider the cost of communication.

@hax: I would not simply do a === Number(b) either, not without a comment, as I have also had other developers come along and change that to just a === b, seeing only one form of the data, thinking the Number(b) was unnecessary. 🤷‍♂️

The "cost" of communication is not very large when it is a comment right in the code, right where it needs to be.

A developer who would think it’s safe to casually remove an explicit type coercion likely would also casually remove a comment, believing it to be irrelevant :-)

I do not like the change to ??. at all. I fail to see what the improvement is over ?., and it is much more verbose.

@0rvar, I believe it was already decided to seek stage advancement with the current spec. The current spec uses ?.
It is my understanding that this pr will not be merged. After stage 2 is reached this repository will undergo some cleaning and PRs and issues will be closed.

This is a summary of issues I've read over the months.

I think many of us are leaning more towards ?. these days, so I'm closing this PR for clarity. We can reopen it if we see a need to revisit it later.